$1265C - Controls animation stuff for physical attacks?
	Loads pointer to anim table in $08223EFC area, plus number of entries to process
	Loads the I/O pointer for an entry, stores the halfword to that address
	Repeat for the next anim entry for however many entries are specified
	$1267B

$14CF8 - Routine that determines the size of a TSA header, and skips over it to the start of TSA data?
	-Reads byte +$6 in header; uses that as byte index + 0x81AE280; multiplies by input r1; adds 0xC
	-So, TSA headers are always 12 bytes or larger?
	
$14E38 - Given pose ID in r1, advance to that position within decompressed spritesheet

$14E4C - Given pointer to uncompressed tile graphic in memory, find its total size in bytes

$15120 - Short routine that does some storing...related to I/O screen effects

$156CC - Handles palette cycling from a spell aura in-battle...stores palette tint for the current frame
	I don't really understand the math going on, though
	r0 = offset to store current palette tint to
	r1 = offset of unit's colour to tint to/from?
	$1577F

$1E2FC - Some spell animation loading routine?

	r0 - pointer to (pointer to?) variable memory?
	r1 - Animation ID
	r2 - Which unit is casting the spell (from 0x0 to 0xC)
	r3 - Which unit to play the animation against (for ST spells only?)
	[sp+$70] - Whether spell is ST or MT? Or whether caster is monster or PC?
		-But why not just calc from caster's actor ID..?
	--For details, see attached ASM file--

$1EAA8 - Used for spell animations...loading BG overlay?
	r0 - A memory pointer
	r1 - Pointer to compressed tile data
	r2 - X-offset in tile data
	r3 - Y-offset in tile data
	[sp] - 
	[sp+4] - 

$1EC74 - Wipes out GFX data?
	-For stuff that wants a transparency effect by blinking in and out?

$1F0DC - Utility anim code
	r0 - contains mem pointer to anim script
	r1 - param 2
	r2 - param 3
	Branches depending on value of param 2; must be within 0x0-0x6
		$00: Return 0x1
		$01: Load BattleMem to r0, param 3 to r1; branch to 0x70214
			-Check if the unit of ID r1 may be targeted; return 0x1 if so

		$02: Loads r0+$B57C (unit ID of caster)
			-If 0x3 or higher, return 0x0; else return 0x1

		$03: Loads r0+$B57D (unit ID of target(s))
		If value there is 0x4 or higher, return 0x0; else return 0x1

		$04: Checks action effect structs in BattleMem to see if target(s)
		had a status effect set
		-If any unit was affected, return 0x1; else return 0x0

		$05: Same as $01
		$06: Checks encounter ID for special type; if equal to param 3 return 0x1; else 0x0

$1F130 - Run for each target to determine if that target will have the effect played
	-Uses similar conditionals as the above routine
	-See Animation Data.txt

$1F1A4 - Handles storing a spell's animation data to WRAM
	-Each chunk is X amount of words long, where X is indirectly indicated by the first byte in the chunk
	-Further, pointers to each of these chunks are also stored in memory
	-Called whenever it's necessary to transfer the next set of anim data to memory

$1F864 - Routine called every frame during PC attack/spell animations
	Both for physical attack anims and spells
	If memory address containing script command ptr is nonempty, reads byte pointed to
	and indexes to 1D94C8 anim routine table

$1FE7C - Code for animation script command 0x25
	-Cycles PC palettes once if they haven't been already

$1FF8C - Unknown - loads PC GFX/palette ptr table
	-Gets ?? PC's class byte, uses that to index to GFX/Palette table; loads GFX ptr
	-Then a whole lot of other stuff

$20F64 

$21894 - Code for animation script command 0x9
	Load param (+$C); store to somewhere +$B588
	Load param (+$A); store to somewhere +$B58A
	Load param (+$8); store to somewhere +$B58C

$21914 - Code for animation script command 0x6
	-First do delay checks from param 1
	-Once delay is finished, load params 2 and 3, jump to $1F0DC
	-If 0x1 returned, load param 4 (+$10); if 0x0 returned load param 5 (+$14)
	-Store this param to the memory address indicating where to continue loading commands from
	-Calls 0x1EC74

$21B78 - Code for animation script command 0x17
	-Does different things depending on Path parameter, but the root handles some basic stuff
	-Stores script params to AnimDat struct, handles origin point calculations

$2296C - For command 0x17, path type 0x7
	-Does a lot of stuff related to params...
		-First time through, sets starting/ending coords; subsequent runs move the object?
	-Adds target's coords to param coords to determine destination of moving object
	-Loads pointer to 0x081D982C to get initial coords, etc
	$22A40: responsible for moving the animated object
		(see Anim Path 7.asm)
	AnimData struct is used like so:
		+$00: Some tile identifier
		+$04: Coordinate params
		+$08: Segment/run count (for repeating commands, tile movement etc)
		+$0C: current x-coord
		+$10: current y-coord
		+$14: distance along current segment
		+$18: Target X-coord for current segment
		+$1C: Target Y-coord for current segment
		+$20: X-displacement from target (based on target X-coord)
		+$24: Y-displacement from target

$242A0 - For command 0x17, path type 0x14
	-Set starting pos offset to 0x20 (to the left)
		-Or if target is a monster, 0x20 to the right
	For first run only:
	   -Gets coord param * 0x2A and puts into displacement
	   -Then gets coords of object, puts into AnimData
	   -Loads 0x22F764; adds (Disp+0x40)*2; loads signed halfword there;
	  store to AnimData struct+0x1C (X-displacement)
	   -Loads 0x22F764 + (Disp)*2; load signed halfword there;
	  store to AnimData struct+0x20 (Y-displacement)
	   -Get X-disp * 3/32
		-If bit 0x80 set, set all higher bits too
	   -Get neg(Y-disp*24) >> 8
		-If bit 0x80 set, set all higher bits too
	   -Add starting X to modified X-disp, subtract by starting pos offset;
	  store to AnimData struct +0x14
	   -Add starting Y to modified Y-disp, store to AnimData struct +0x18

$24C64 - For command 0x17, path type 0x18
	Overall, gets the difference between the starting coords and destination coords,
	divides by 25, advances by that offset every run
	At certain intervals, changes the animation frame of the object and eventually erases it
	X-destination is 0xF0; Y-destination depends on input parameter
	-Gets X,Y coords of object, stores to AnimData struct
	-Set "distance along segment" value to 0xF0
	-Load pointer to 0x081D99A8; add (pathParam*4) to it; load halfword there
		-This indicates Y-coord to head for!
		-Store to AnimData struct+0x18
	-For params 0,1,4,5, depending on origin's coords, use alternate dest Y-value
		-0,1 make it smaller if origin is too low and far to the right
		-4,5 make it larger if origin is too high up
		(probably so that you always get the whole party being blasted no matter what)
		-Load alternate Y-dest from (pathParam*4) + 2

$292F8 - If ?? unit is a PC, get class byte to get class's tile arrangement data ptr
	-Then other stuff happens

$29AD0 - Code for animation script command 0x11
	parameter +0x24 governs when to end movement?
	If 0x40000000, end when x-coord exceeds 272,
	or when y-coord is less than -16 or greater than 136

$2AD90 - Change animation frames of object of given ID, or remove it
	r0 = ?
	r1 = ID of object to change
	r2 = anim frame to set
	r3 = ?
	[sp] = ?

$2AE04 - Pointer table for something to do with anim command 0x17
	-Table of routines to jump to, one for each path type

$2B1A6 - Part of an animation-related routine...
	-Loads spell anim's anim data pointer, loads first byte in the entry
	-Not sure what this byte really does, though...Fire animation shows no differences

$2B504 - Given object (tile?) ID, gets Y-coord of object
$2B534 - Given object (tile?) ID, gets X-coord of object

$2B564 - Given object ID and coords, set current coords

$1F1B6,$6AD5C,$7A1F0 - These routines repeatedly check if the 'current animation' is zero; 
	once it is, the caster moves back and battle execution can continue

$3AE08 - given pointer to palette data in palette mem, greyscale-ify r1 colors

Pointers to class GFX tables:
0x45C58
0x48478
0x49480
0x4B944 (for base class)

Pointers to 0x2230FC table specifically:
0x01FD48
0x020044
0x0293D0
0x0733D0 (known - for petrification curing)
0x0737F4 (known - animating PC sprites inbattle)
0xEDF174

$67270 - Loading a map sprite base routine
	Given map sprite ID, checks if that ID is extant in the map already
	If so, don't bother loading the same GFX twice
	If not, index to map sprite settings to get GFX/palette/arrangement


$0696D0 - updating coordinates for tiles along a path
	Essentially calculates fractions of the target X/Y coords to move object along a path
	Varying the fractions allows for curves and such
	r0,r1 = offset of current final x/y coords to store results in
	r2 = X-offset Ox
	r3 = Y-offset Oy
	
	[sp] = updated path distance AKA U
	[sp+4] = target X coord AKA Mx
	[sp+8] = target Y-coord AKA My
	
	load $822F764, SET
	
	get U+0x40 * 2, add to SET; multiply signed halfword there by Mx
	then >> 8, add to Ox, store to current x-coord
	
	get U * 2, add to SET; multiply by My
	then >> 8, add to Oy, store to current y-coord

$06A648 - Called once at start of battle
	-Sets up I/O stuff, arrangement of windows, etc...

$06D4B4 - Big preparation for physical attack animations

   $06D542 - Loading weapon ID for animations
   $06D8F4 - For monsters, uses their ID to index to table at $223540 to get attack animation
		-Then adds 0x2D to the animation value found there before storing to memory
   $06D944 - For shield blocking anims; loads shield's GFX data
	Also checks for shields $24,$28,$29: Protect Cloak, Zephyr Cape, Elven Cloak
		-So, they play the 'cloak' animation/sound
	

$06DC60 - Some huge animation routine...run when opening battle menus, at start of battle,
	when a PC's turn comes up and they're about to move forward...

$0704F4 - Called during sprite determination routine...
	-Loads ROM pointer from [20004D8], stores some data from that and parameters to memory
	-Controls stuff like how far forward a character steps before doing their action

$07054C - Another sprite related routine...sprite animation part 2
	-Man, this stuff is really involved
	-Oh Lord, it's recursive!
	-Run for every sort of sprite state, including, eg, the idle casting anim
		-So, if the casting anim is set to move the user, they'll constantly slide around
		-Well, they'll move every other tick since it's two states alternating

$070700 - Sprite-related...runs constantly for every party member too
	Finding X-Coord, plus or minus some values determined by input r2
	Takes input from r2....must be less than $E
	-Not just for units! Also for cursor position in menus, spellcasting effects
	Part 1:
	$5: Return 0x28 immediately
	$6: Divide ID by 3; set result to values depending on ID...
		-But, if one of the last PCs or monsters, determine normally
	$7: If ID is even, return 0x00; if odd return 0x78 (for menu cursors)
	$8: Equip menu: Return 0x00
	$9: Do the same as the out-of-bounds values
	$A: Equip change cursor: If ID is even, return 0x00; if odd return 0x74
	$B: Return 0x98
	$C-D: Return 0xE0
		If was not 0x5-0xD:
		If PC, go to BattleMem + ([$4B86]+UnitID)*72 + $450
		Load halfword from [that+$3A] = X-Coord; set sub_value to $C
	
	Part 2:
	$0-1: Subtract X-Coord by sub_value
	$2: Subtract X-Coord by sub_value;
		-If PC, further subtract 0x10; if monster subtract 0x8
	$3: If unit is PC, subtract X-Coord by sub_value; else don't (for printing damage/healing/'miss')
	$4: If unit is PC, subtract by (X-Coord + 0x18); else don't
	$5-8: Set X-Coord to 0xFF
	$9: Subtract by sub_value and add 0x8; if monster further add 0x10;
		-If less than 0x10, return 0x10
		-Used for status effect bubbles
	$A-D: Set X-Coord to 0xFF (won't reach here)
	$E: Return X-Coord unmodified

$070898 - Very similar routine to the above - determines Y-coord, plus or minus some value
	- Depends on what the caller is doing - printing damage numbers, displaying status bubble, etc...
	-in the struct accessed, loads +$3C to get Y-coord

$070A5C - Routine handling the flashing effect when a monster acts
	-Called by routine at $70B20
	-r1: which monster to flash?
	-r2: palette to flash to? 0x0 resets to normal
		-0x0: (Reset to normal palette)
		-0x1-0x5: BG Palettes
		-0x6-0x9: Monster Palettes (depending on how many monster types)
		-After last monster palette comes the 'all bright' and 'all dark' palettes
	-Loads r1th monster's $4C pointer
	$70AD8: This may be where the monster's GFX data is modified...
		-Halfwords are AND 0xFFF, ORR with r2 param
		-Repeat for every tile in every row of the monster's GFX?

$070B20 - Monster palette cycling handler? 
	Gets currently active unit, subtracts by 4 -> this is for monsters
	Loads byte at BattleMem+$535A; if 0xFF, return 0x0 and exit
	Increment value and stores (but use old one for further calcs)
	If 0x11 or more, return 0x1 and exit
	else:
		$0: Copies BattleMem data:
			Halfword at $4C16 to $4C18
			Halfword at $4C6A to $4C6C
			Byte at $4C60 to $4C61
			Byte at $4C84 to $4C85
			Copy 0x400 bytes from $600E00 to [BattleMem+$4AD8]
			Copy value from BattleMem+$4C84 to [sp+0x0C]
			Branch to $014E10...some weird stuff
			Stores [+$4C6A] to sp+0x10, loads pointer $83C329C
			Branch to $14DCC
			Does some other nonsense, like copying that data to WRAM
			Eventually starts the palette stuff
		$1-3: Return 0x1
		$4: Load byte BattleMem+$535B; add 0x1; branch to $070A5C!; return 0x1
		$5-7: Return 0x1
		$8: Load byte BattleMem+$535B; add 0x1; branch to $070A5C, return 0x1
		$9-B: Return 0x1
		$C: Load byte BattleMem+$535B; add 0x1; branch to $070A5C, return 0x1
		$D-F: Return 0x1
		$10: Branch to $070A5C for palette 0x0 (restore normal)
			-Copies BattleMem data:
				Halfword at $4C18 to $4C16
				Halfword at $4C6C to $4C6A
				Byte at $4C61 to $4C60
				Byte at $4C85 to $4C84
			-Store 0xFF to BattleMem+$535B; return 0x0

0x70D68 Routine for flipping an enemy's sprite
	-Sets 0x400 in each of the monster's GFX halfwords

0x70E60 Routine for displaying *multiple* targeting pointers, for target-all spells
	-Sets or unsets flag for each unit to be targeted to create the flickering effect
	-Uses BattleMem + [($1C+targ_index)*72 + $493] to store the booleans in

0x70EFC - Routine called once when selecting a multitarget spell
	Input r1 denotes whether targeting party (0x0) or monsters (0x1)?
	Determines positions of targeting arrows for all (living?) targets

0x710FC - Routine called once when exiting out of a multitarget? Clears all targeting arrows

0x71150 - Called when displaying damage or healing
	r0: BattleMem pointer
	r1: Unit ID to display for
	r2: ? Specific to a spell?
		0x01: normal/damage?
		0x11: miss?
		0x125: healing?
	r3: Healing/Damage amount

	Store 0xFF to [sp+4~7] (for damge numbers in decimal), then find unit's coords and store to stack
		-X coord to sp+$1C, Y coord to +$20
	Load byte from BattleMem+$2876, store to [sp+$24]
	Load byte from BattleMem+$4B81; lsl 0x1; add 0x10; add to pointer from BattleMem+$287C;
	Load byte THERE and store to [sp+$28]
	Then, check for 0x10 set in r2Param (miss flag?)
	If not set:
		-Check for bit 0x20 (healing?)
			-If set, add #0x28 to [sp+$28] value; if not, add #0x14
		-Branch to 0x15838, using damage amount as input:
			-Converts number to decimal? Stores each digit in consecutive bytes in [sp+4],
			and returns number of decimal digits in r0
		-Load UnitID of target and X-Coord
			-If unit is PC, subtract by 0x1C
			-If monster, subtract by (10-UnitID)*4
		-Load Y-Coord, lsl 0x10 (2 bytes up), store to [sp+0x30]
		-Put pointer to BattleMem+$4B94 (number of multitarget arrows?) in r10
		-Clear some space in the stack; store $83ABDCC to [sp+0xC]
		-Start storing coords to place the numbers at to stack...we're in a loop

0x71458 Called whenever a physical attack is about to happen
	Sets up animation parameters for the physical attack
	Does lots of branching depending on if attacker is PC/Monster, other parameters
	r0 = BattleMem base offset
	r1 = Attacker's Unit ID (for gfx purposes...)

	Does some bookkeeping with BattleMem stuff (in 51E8, 450 structs)
	Gets attacker's X and Y coords; save in r8/r7
	Also has attacker's ID from +$51E0 saved in r9

0x716EC - Applying a status effect bubble to a unit's sprite
	r0->r7 = BattleMem offset
	r1->r6 = unit ID
	r2->r8 = Status effect to apply
	r3->r9 = If 0x1, target can't attempt to recover from Sleep/Paralysis this turn
		-Tends to be 0x1 except when called from status effect recovery routines
	-Move FF to r2, 0x0 to r3 (but if unit is monster, move 0x8 instead)
		-This controls whether to horiz. flip the bubble direction or not
	-Valid status effects and their return values:
	$04 - $04
	$08 - $03
	$10 - $02
	$20 - $01
	$40 - $00	-Bubble ID to print
	Anything else, including Confusion or multiple status effects - exit routine immediately
	Anyway, branches to $014750 to store a bunch of stuff to unit's GFX data struct
	Then calcs coords to place status effect bubble at, stores those too
	Also stores the ailment ID to unitData +$5
	Now, if r9 = 0, exit now
	Otherwise, store 0x1 to target's unitData + $34, and then exit

0x71828 Some status effect routine...called when a unit has recovered from an ailment?
	r0 = BattleMem
	r1 = Unit ID to affect
	r2 = Ailment to remove
	If current status ailments are only Confusion or Death, or wasn't recovering from anything,
	then clear status effect bubble?
	If ailment to remove and current displayed ailment are different, exit immediately
	Otherwise, set the unit's status bubble to the highest-priority status:
		-Silence-->Sleep-->Paralysis-->Blind-->Poison

0x718F4 Run at the end of every action; redraws all units' status effect bubbles?

0x719AC Run at the end of every player character's action; loops through all PCs
	-Loads unitData + $4; AND 0x01
	-If not set, AND 0x02
	-Checks for Blink/Invis visual effects on the character

0x71C38: For active unit, copies coordinates from battle data struct to 'animation data' struct

0x71D40: Called repeatedly during battle: PC sprite aura/tint control
	Loads byte at BattleMem +$48E6; if zero (palete cycling disabled) skip all
	Calculate and store current sprite tint for every PC
	-Next load BattleMem +$28E5 (tint cycling direction)
	If 0x0 (increase):
		-Increment value at BattleMem+$28DC by BattleMem+$28E0 (tint cycle count)
		-If total exceeds 0x200000, instead store 0x200000 - [BattleMem+$28E0] to +$28DC,
		and reverse direction
	If 0x1 (decrease):
		-Decrement sprite tint cycle count by tint cycle step
		-If would be below zero, just store the tint cycle step and reverse direction

$71E20: Calls the above; is itself repeatedly called. Also does some BattleMem bookkeeping

$725F8: Called twice during (critical?) hits, on consecutive animation frames;
	if r1 is 0x1, stores 0x08223F2C to BattleMem+$4A10
	if not, stores 0x08223F3C to BattleMem+$4A10
	Either way, both separately store 0x2 to BattleMem+$4A14
	r0 = [BattleMem+$49FC]; r1 = BattleMem+$4A00; branch to $015210
		-That does some storing

$72670: Called continually during a monster's death animation, and at start of battle
	-If the monster is one of the following, return 0x1:
		-Cockatrice, Pyrolisk, Poison Eagle
		-Gargoyle, Horned Devil, Rock Gargoyle
	-Else return 0x0
$7269C: ? ANDs and ORRs some numbers, eventually stores halfword to input [r1]
$726D0: ? Similar stuff here...stores a byte to input location at [sp+8]

$72774 Called at end of a combat round - clear WINDOW0 and WINDOW1
	Store 0x8223F1C to BattleMem+$4A10, 0x2 to +$4A14; will process two effects
	r0 = [+$49FC]; r1 = +$4A00; branch to $15120
	Schedules some I/O effects - $223F1C,$223F24 clear all windows

0x727B0 Run at the start of any unit's action; sets default I/O behaviour
	-Specifically, for the window at the bottom that holds PC/monster stats, menus etc
	-Runs I/O changers $223EFC, $223F04, $F0C, $F14
		-Set WIN0H dims:  0p to 240p (well 248 but it'll be truncated)
		-Set WIN0V dims: 160p(bottom) to 120p (top)
		-Allow BG0-BG3, OBJ, Colour FX (ie all) outside of windows
		-Allow BG0, BG2, BG 3 in Window 0; and everything in Window 1
	-Also branches to $15210

0x727EC Called when an animation of any sort is about to take place, and twice at the end of a round
	-Physical attack, spell anim...
	Overall, initializes each unit's 'current action effect' RAM struct
	-First, zero out/reset 'unit action effect structs' w/ CPUSet:
		-Load BattleMem+$51E0 (unit action effect structs)
		-Also load 0x05000041 (params for CpuSet - fill, word, 41)
		-Store 0x0 to [sp] - fill byte
		-Branch to 0x818C074 (CPUSet)
			-Fill 0x41 words of 0x0 (0x0) to BattleMem+$51E0
		-Put BattleMem + $51E1 to r12
		-Now, for every unit 0-12, store 0xFF in their +$1 (was affected) byte
		and also store 0x01 in their +$C hw (some bitfield?)

0x7284C Called continually during battle
	Load BattleMem+$49FC (I/O related); branch to 0x07DB44
	That's all!

0x72868 Small routine...called at the end of physical/spell attack animation
	(if multiple hits, is called multiple times)
	-Set BattleMem+$48E6 to 0x1 - enable PC palette cycling
	-Set +$28DC, +$28E5 to 0x00000000 and 0x00 respectively

0x7288C Reset palettte tint for all PCs and disable palette cycling/tinting
	Usually called at end of a spell animation
	unless that spell ended the battle....
	Or PC palette tinting was already turned off for some reason
	-Also called by spells which mess with palettes as part of their animation
		-Silence, Vox, Mind Blast, Stun, Focara, Diaja...
	Load [BattleMem+$4BEC] into r5
	Load BattleMem+$49EA into r4
	-For every PC unit:
		-Load halfword from r4 + unitID*2
		-Store to r5 + unitID*32
	-Store 0x0 to BattleMem+$48E6: Stop palette cycling
	-So...resets palette tint for all PCs, and does something else

0x728CC Called when a PC unit is killed or stoned
	r1 = unit ID
	Advance to unit's spot in [BattleMem+$4BEC] table
	Reset PC's palette tint
	Stores unit's Tint 1 (default) to BattleMem+$49F2 (Tint 2), removing applied aura/palette tint effects

0x72904: Called when a spell is applying an aura to PCs
	r1 = Unit ID
	r2 = Index to 0x083B16C0 colour
	r3 = Sprite Tint cycle length (all callers use 0x78 as it happens)
	Load 0x083B16C0 (list of colors?); branch to 0x14E10 (weird stuff)
	Branch to 0x14DA8 (put 0x83B16C0 + (r2*4) + 8 into r0)
	Load the colour halfword at that offset, and store it into the given PC's +$49F2 entry (set palette tint)
	Store r3 / 2 into BattleMem+$28E4
	Then, store (0x200000 / (r3/2)) into BattleMem+$28E0 - this controls how quickly to cycle the sprite tint
	Then branch to 0x14F10 (will always do nothing in this case?)

0x72A50: Called every frame during a death animation
	-Counts the number of monsters still undergoing their death animation
	-If at least one is, return 0x0; if none are return 0x1
	
0x72A88: Called when a spell is about to be cast, just before animation starts
	Does something with every PC's sprite

0x72AC8: Called when a spell is going to be cast (spell name just displayed)
	For every unit:
		Loads [BattleMem+$4B91], adds unit ID, multiply by 0x48 and add to BattleMem+$450
		-Store 0x0 to +$43
0x72B00: For a given (active?) PC, advance to animation settings struct, load +$0F byte
	-To check if given PC is still going through an animation?

0x73358: Called only after a Petrification-curing spell in batle
	-Restores PC's gfx/palette to normal?

0x733E8: Called during every animation frame when a PC is animating
	-Simply determines what sprite to draw, and invokes CPUSet to do it?

0x75074 Routine for loading monster GFX using tile arrangement data

	0x75100: Loads monster's ID; if ID is between $80-$90 (Soul of Chaos bosses),
	use an alternate set of calculations going forward

	Otherwise:
	Load monster's palette pointer; load some other stuff; branch to $14EB0,$14E4C,$14E38
	(determines where to put palette?) branch to $818C074 to store palette to VRAM

0x755C8 Monster death animation-related; calls $72670
	Loads monster's Unit ID and from there its Monster ID; checks if monster is a flyer;
	If it is and r7 > 0x17, clear out some additional pixels from the monster's sprite?
	
0x75658 Monster death animation-related: erase one line of pixels
	For bosses, only starts being called partway through death animation
	r1 = unit slot
	r2 = pixel line to erase
	r3 = For boss monsters, use in part to determine what of the below to load and where to write
		-Some bitfield of stuff to get rid of?
		-Lower bits select which ROM halfword to use from both 8-byte chunks
		-Upper bits help select what parts of the sprite to erase
	Copy "FC FC F0 F0 C0 C0 00 00" and "3F 3F 0F 0F 03 03 00 00" to [sp] (from ROM)
	Gets this monster's VRAM data pointer from unit data
	Based on monster's size byte, and indicated line, zero out one line of monster's sprite data
	...or if you're a boss-sized monster do something else presumably
		-Seems to get one of those ROM halfwords from earlier using r3 param
		-Then,use params to find sprite area to modify
		-AND two halfwords with the ROM halfword
		-Get second ROM halfword from second half of ROM chunk
		-Do the same with another section of VRAM data
		-Anyway, for bosses this routine only handles erasing lines
			-The 'splitting' effects happen elsewhere, perhaps in the calling routine

0x75794 Big routine, checking for encounter type + dead monster
	r1 = Unit ID
	-For monster death animations?
	Take r1-4
	-If given monster is dead, branch based on encounter type:
	$4 (Tiamats): 
	$5 (Miniboss): If encounter ID is 0x7C (ie Vampire, small guy) load $22A631
		Else load $22A651 (Astos, Garland)
		Divide r9 (frame counter) by 4 and index to the byte in that table
		Then get some params together and branch to $075658
		Then, if Enc.ID = 0x7C, set limit as 0xAC; else 0x10C
		Compare r9 (frame counter) to the limit; if equal do some extra stuff
		Anyway check if r9 is even or odd and do different things
		Then if r9 is greater than limit, do some extra stuff; else exit out
	$6 (Normal): Load dying monster's size, and +$43 byte (monster pixel height?); subtract by 1...
		Depending on monster size, load different byte table, and index using r9's value
		r9 ++ each time a given monster comes around...this table indicates which line of
		pixels to get rid of
		Do that for the indicated line; now compare r9 (number of lines erased) with r7 (number of lines total)
		If r9 is greater, the death animation must be finished; so remove this monster
			from the death animation queue.

$75E0C - Called repeatedly at start of a Fiend death animation
	Handles the screen flashes at the start of a Fiend death animation
	-Each time it's called, it increments a memory counter and checks against value
	At first:
	at $0822A681 + (other memory value); if the two are equal, brighten the whole screen except the menus
		-And branch to $818ABFC, which does some funky stuff
		-Then increment the other memory value
	Does other stuff after that depending on if screen is brightened or not, etc

	At last, store some bytes to memory; checks encounter ID; if 0x7 (SoC boss), store slightly different bytes


$75F30 - Called repeatedly during second part of Fiend death animation
	-Gives it a 'rumbling' effect
	-Used to shift a boss's entire sprite horizontally by a few pixels
	r2 = sprite line to shift
	r3 = shift offset (signed)

$760E4 - Called during CHAOS's death animation
$761C8 - Called during CHAOS's death animation
$7640C - Called during CHAOS's death animation

$76490 - Called periodically by $75534, once for each PC
	-Indexes to PC's +$5128 anim settings struct
	-Also indexes to +$450 struct, puts X/Y coords into r8/r9
	-Anyway, loads +$10 from anim settings; if nonzero or if PC is animating, continue; else exit
		-Seems to redraw PC's sprite, if it needs redrawing?
		-Also changes PC's coords if needed!

$76E9C - Unknown PC animation-related

$078E48 - Handles physical attack animations relating to PCs
	-Goes to different code depending on input memory value
	-Loads from BattleMem+$51E0 attack effect struct
		-Gets attacker's ID
	-If attacker is a PC, load equipped weapon ID
		$00
		-If bit 0x10 isn't set in attack effect + $0C, skip lots

		$0A
		-??Check if PC has any weapon equipped

		-Set index to $0B
		$0B
		-Stall for five frames
		-That done, on the sixth go-around, play the equipped weapons' hit effect animation on target
		-Set index to $0C
		$0C
		-Do nothing until weapon animation finishes
		-When weapon hit effect anim is done playing, reset PC attacker's sprite and start another swing if allotted
			(number of swings is defined in memory)
		-Once all swings have been taken, do some bookkeeping and return 0xFF

		$0F
		-Checking if PC defender blocked with shield?

		$14
		-For monster attackers; handle hit effect animation
		-Load attack animation ID from memory; branch to $1E2FC
		-Set routine index to $15
		$15
		-Handle making PC targets animate in response to the physical attack, if it hit

$7952C - Called when printing damage numbers/miss text after an action
	-Loops through every unit's BattleMem+$52E4 struct, checking if they were affected by current attack
	-Increment their counter (until it reaches 0x1B - then don't offset)
		-Use it to increment to position in $22F5CC table, to determine relative
		Y offset of damage number
	-Go into anim tables for the up to four digits and increment Y coords
	-Then decrement timer in +$52E4 struct
	-Once damage display animation is finished, return 0x1

$0796C4 - Run frequently during battle
	-If BattleMem+$534C is zero, exit immediately
	-Otherwise, load BattleMem+$5350 and add 1; if result is negative, exit immediately
	-Once zero is reached, load +$4B90 byte and use to index to +$450 table
	-Store 0x1 to the entry +$43; repeat for consecutive entries up to the number stored in +$435C
	-When BattleMem+$5350 is above zero, just decrement +$5352-3 (animation timer?)
	-When timer reaches zero, store 0x0 to the animation entries' +$43

$079764 - For all targets affected by current action, print damage/healing/miss
	-Reads attack effect structs to determine who to print for
	-Also copies byte from BattleMem+$4B95 to +$4B8D

$07D03C - Run when about to print damage numbers, or when displaying save files!
	-Handles some gfx-related stuff
$07D110 - Unused routine related to damage numbers printing; very similar to $7D1CC, which is used
$07D1CC - Called to spawn a new animated thingy in battle?
$07D2C0 - Related to spawning new animated thingy in battle?
$07D410 - Related to animated objects...
		-Load object's anim data; add +$3A and +$3E, add and store to +$3A
		-Do the same with +$3C and +$40	
		-Move object's offset in screen, if called for

$07D4B4 - Master update routine for all animated objects?
	-Loop through all objects in BattleMem+$1C10 listing, checking if update needed?
	-If object has 0x00 in +$43 and +$44 in anim data table, don't update
	-Do different things depending on if +$43 or +$44 are nonzero

$07D5F8 - Maybe this is used to create new animated object??
	-Inputs are two object IDs
	-

$7D938 - Animation-related...called when physical attacks happen per visual hit

$18ABFC - Given Sound ID, finds sound pointer and does the needed
	-Only run for spell/weapon sounds?

$1BF050 - contains two pointers, both to animation pointer lists
	-First is for spell animations, second is for weapon impacts
	-0x81BE540
	-0x81BEC80

$1C0470 - Animation data, for Blind
	-Controls how GFX is used, plays sound effects, loops for every target...